08-12-2019 03:10 AM
I have setup a SIP trunk for our office in Germany. Deutsche Telekom insisted we had to move off ISDN, as they are replacing it with SIP. I used the following guide as help me https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/connecting-unified-communication-manager.pdf
Our setup has 1 Cisco router and is used for routing over our MPLS network, , IWAN, and now the SIP connection. It is a 4331 running 16.03.07. I had to route 217.0.0.0/16 out the SIP port to get calls working. So I want to secure this connection to only trust Deutsche Telekom. Ideally I would use vrf for the SIP trunk so its routing is separate.
My Interface is configure as:-
interface GigabitEthernet0/1/1
description Deutsche Telecom Interface
ip address 192.x.x.2 255.255.255.0
negotiation auto
SIP-UA config:-
sip-ua
credentials number +49*********90 username 55************** password 7
********************* realm sip-trunk.telekom.de
authentication username 55************** password 7 *********************
no remote-party-id
timers expires 900000
timers register 100
timers dns registrar-cache ttl
registrar dns:sip-trunk.telekom.de expires 240 tcp auth-realm siptrunk.telekom.de
sip-server dns:sip-trunk.telekom.de
no transport udp
connection-reuse
How do I trust only 'sip-trunk.telekom.de' and create an access list without an IP address?
For vrf, do I need to reload the router to get the once I have created the vrf definition to activate the new route group? I could not seem to get vrf working when I last tried to apply it to the SIP interface.
Many Thanks,
Mike
Solved! Go to Solution.
08-12-2019 04:29 PM - edited 08-12-2019 04:31 PM
Hi Mike,
"How do I trust only 'sip-trunk.telekom.de' and create an access list without an IP address?"
Extended ACLs have a hostname parameter you can use but as far as I know it just does a name look up the first time you configure the ACLs and resolves it to an IP address and saves to the configuration. So unless this has changed, this serves you no good. You still have to manually re-enter the command to update the IP.
You can use VRFs. ISR4Ks even support multi-vrf feature. That means you can configure the provider facing interfacing in a separate vrf say VRF-SP and CUCM facing interface in a different vrf say VRF-CUCM. You dont need any route leaking, CUBE will provide the bridging for the voice calls. In this case Cisco do recommend you reload the router after you make any changes with the VRF configuration. Multi-vrf has some limitations, as listed below. If you don't need to use these features listed in limitations, multi-vrf CUBE with the SP and Corporate facing interfaces configured in a separate VRF is the best way to segregate the IP between the corporate and SP network.
The document refereed below has the config guide as well explains the dial-peer matching as well for the multi-vrf setup.
Supports only SIP-SIP calls.
Cisco Unified Communications Manager Express (Unified CME) and CUBE co-located with VRF is not supported.
Cisco Unified Survivability Remote Site Telephony (Unified SRST) and CUBE co-location is not supported prior to Cisco IOS XE Fuji 16.7.1 Release.
Multi-VRF call across CUBE is supported in Flow-through mode only.
IPv6 on VRF is not supported.
SDP pass-through is not supported prior to IOS Release 15.6(3)M and IOS XE Denali 16.3.1.
Calls are not supported when incoming dial-peer matched is default dial-peer (dial-peer 0).
Media Anti-trombone is not supported with VRF.
Cisco UC Services API with VRF is not supported.
Multi-VRF is not supported on TDM-SIP gateway.
VRF aware matching is applicable only for inbound dial-peer matching and not for outbound dial-peer matching.
Invoking TCL scripts via a dial-peer is not supported with the Multi-VRF feature.
Multi-VRF using global routing table or default routing table (VRF 0) with virtual interfaces is not supported on ISR-G2 (2900 and 3900 series) routers.
SCCP based media resources are not supported with VRF feature.
For new deployments, we recommend a reboot of the router once all VRFs' are configured under interfaces.
No VRF Route leaks are required on CUBE to bridge VoIP calls across different VRFs.
High Availability(HA) with VRF is supported where VRF IDs are check-pointed in the event of fail-over. Ensure that same VRF configuration exists in both the HA boxes.
Whenever destination server group is used with VRF, ensure that the server group should have the session targets, belonging to the same network as that of sip bind on the dial-peer, where the server-group is configured. This is because, dial-peer bind is mandatory with VRF and only one sip bind can be configured on any given dial-peer.
If there are no VRF configuration changes at interface level, then reload of the router is not required.
Note | We recommend you NOT to modify VRF settings on the interfaces in a live network as it requires CUBE reload to resume VRF functionality. |
This section provides the generic configuration steps for creating a VRF. For detailed configuration steps specific to your network scenario (Multi-VRF and Multi-VRF with HA), refer to Configuration Examples section.
08-12-2019 04:29 PM - edited 08-12-2019 04:31 PM
Hi Mike,
"How do I trust only 'sip-trunk.telekom.de' and create an access list without an IP address?"
Extended ACLs have a hostname parameter you can use but as far as I know it just does a name look up the first time you configure the ACLs and resolves it to an IP address and saves to the configuration. So unless this has changed, this serves you no good. You still have to manually re-enter the command to update the IP.
You can use VRFs. ISR4Ks even support multi-vrf feature. That means you can configure the provider facing interfacing in a separate vrf say VRF-SP and CUCM facing interface in a different vrf say VRF-CUCM. You dont need any route leaking, CUBE will provide the bridging for the voice calls. In this case Cisco do recommend you reload the router after you make any changes with the VRF configuration. Multi-vrf has some limitations, as listed below. If you don't need to use these features listed in limitations, multi-vrf CUBE with the SP and Corporate facing interfaces configured in a separate VRF is the best way to segregate the IP between the corporate and SP network.
The document refereed below has the config guide as well explains the dial-peer matching as well for the multi-vrf setup.
Supports only SIP-SIP calls.
Cisco Unified Communications Manager Express (Unified CME) and CUBE co-located with VRF is not supported.
Cisco Unified Survivability Remote Site Telephony (Unified SRST) and CUBE co-location is not supported prior to Cisco IOS XE Fuji 16.7.1 Release.
Multi-VRF call across CUBE is supported in Flow-through mode only.
IPv6 on VRF is not supported.
SDP pass-through is not supported prior to IOS Release 15.6(3)M and IOS XE Denali 16.3.1.
Calls are not supported when incoming dial-peer matched is default dial-peer (dial-peer 0).
Media Anti-trombone is not supported with VRF.
Cisco UC Services API with VRF is not supported.
Multi-VRF is not supported on TDM-SIP gateway.
VRF aware matching is applicable only for inbound dial-peer matching and not for outbound dial-peer matching.
Invoking TCL scripts via a dial-peer is not supported with the Multi-VRF feature.
Multi-VRF using global routing table or default routing table (VRF 0) with virtual interfaces is not supported on ISR-G2 (2900 and 3900 series) routers.
SCCP based media resources are not supported with VRF feature.
For new deployments, we recommend a reboot of the router once all VRFs' are configured under interfaces.
No VRF Route leaks are required on CUBE to bridge VoIP calls across different VRFs.
High Availability(HA) with VRF is supported where VRF IDs are check-pointed in the event of fail-over. Ensure that same VRF configuration exists in both the HA boxes.
Whenever destination server group is used with VRF, ensure that the server group should have the session targets, belonging to the same network as that of sip bind on the dial-peer, where the server-group is configured. This is because, dial-peer bind is mandatory with VRF and only one sip bind can be configured on any given dial-peer.
If there are no VRF configuration changes at interface level, then reload of the router is not required.
Note | We recommend you NOT to modify VRF settings on the interfaces in a live network as it requires CUBE reload to resume VRF functionality. |
This section provides the generic configuration steps for creating a VRF. For detailed configuration steps specific to your network scenario (Multi-VRF and Multi-VRF with HA), refer to Configuration Examples section.
08-13-2019 01:15 AM
Thanks for the plain English answer. I will organise the reboot, as that sounds like why my vrf did not work last time. I have also added under the sip-ua config 'permit hostname dns:sip-trunk.telekom.de' to further help with the security.
11-26-2019 06:53 AM
Hi mike,
Same situation for me and i need to secure the connection. What you done?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide